Misuse Cases: Use Cases with Hostile Intent

Eliciting security requirements Security requirements exist because people and the negative agents that they create (such as computer viruses) pose real threats to systems. Security differs from all other specification areas in that someone is deliberately threatening to break the system. Employing use and misuse cases to model and analyze scenarios in systems under design can improve security by helping to mitigate threats. Some misuse cases occur in highly specific situations, whereas others continually threaten systems. For instance, a car is most likely to be stolen when parked and unattended, whereas a Web server might suffer a denial-of-service attack at any time. You can develop misuse and use cases recursively, going from system to subsystem levels or lower as necessary. Lower-level cases can highlight aspects not considered at higher levels, possibly forcing another analysis. The approach offers rich possibilities for exploring, understanding, and validating the requirements in any direction. Drawing the agents and misuse cases explicitly helps focus attention on the elements of the scenario. Let’s compare Figure 1 to games such as chess or Go. A team’s best strategy consists of thinking ahead to the other team’s best move and acting to block it. In Figure 1, the use cases appear on the left; the misuse cases are on the right. The misuse threat is car theft, the use-case player is the lawful driver, and the misuse-case player the car thief. The driver’s freedom to drive the car is at risk if the thief can steal the car. The driver must be able to lock the car—a derived requirement—to mitigate the threat. This is at the top level of analysis. The next level begins when you consider the thief’s response. If he or she breaks the door lock and shorts the ignition, this requires another mitigating approach, such as locking the transmission. In focus